Hi, I have one attribute in a link module and I want to modify its value when I modify a requirement in a formal module. When I modify a requirement which have an outlink, I can modify also the attribute of the link because its linkref is stored in my formal module. But when I modify a requirement which have an inlink, if my source module is already opened in exclusive mode by another user, the link attribute cannot be modified.
Then I store the information of that inlink (source mod name, sourceAbsNo, target mod name, targetAbno and link mod name) in a file. I imagine I could create a DXL code running at the next opening (by any user) and forcing the modification of link attribute stored in my file.
I don't know how to run a script at the opening of the module. Does someone have another idea to modify that link attribute when the source mod is already opened in exclusive mode? Estebell - Mon Dec 19 04:46:00 EST 2016 |
Re: DXL code at opening a module There are two answers to this, one technical and conceptual answer. Technical: If you really insist on doing a "delayed" modification to locked module, you can try different things: - Triggers (A DB wide trigger could check pre save, if there are changes to do to the current module and perform them before save) - Batch Scripts (Have an automatic process that monitors the locked items, and writes the changes as soon as possible) - and so on ... BUT: - All these solutions seem to me like a risky, high effort, unstable way to do a very small thing (whatever data you want to store at that link). - You will not have proper history information (since the modification will not be done by the user that triggered the change in the first place) So I will give you another conceptual answer: You should rethink the following points: - Do I really need to store the information on the link, or could I go with the link target (i.e. if the link gets deleted, must that information also be deleted?) - Or maybe is it sufficient to store information only at the outlinks? - If that information you want to store on the inlink really needs to go to the link, are you using the links correctly? Can you reverse the direction? Why does a change to the target system require a change to the in link. If you share some information about the process, we can maybe come up together with a simpler way of achieving what you want to do. Maybe that helps, regards, Mathias |
Re: DXL code at opening a module Thank's a lot for all your advice. Well I'll try to give you some information about our process.
We have some client documents (level 1), system documents (level 2) and product documents (level 3). Level 2 document can sometimes have one document "Overall". We also have tests documents at each level. Our links are created : - from (level-1) to (level) documents. (System requirements satisfy Client requirements). - from test system documents to system documents (Tests system verify System requirements). -from system documents to system overall document (System requirements are implemented throught overall requirements).
We have already studied about doors suspects links but its process is very tough, whatever we do, the link become suspect. We also studied how to manage an object attribute but if the requirement have several links and only one become suspect, we don't know which one is suspect. So we have done our own suspects links by creating an attribute on links. It becomes suspect only when some object attributes change (not all) by a dxl trigger. When the link to be suspicious is an outlink, it works perfectly, but for inlinks, we cannot change its attribute if its source module is not edited.
Regards, Estelle
|
Re: DXL code at opening a module Estebell - Mon Dec 19 08:35:08 EST 2016 Thank's a lot for all your advice. Well I'll try to give you some information about our process.
We have some client documents (level 1), system documents (level 2) and product documents (level 3). Level 2 document can sometimes have one document "Overall". We also have tests documents at each level. Our links are created : - from (level-1) to (level) documents. (System requirements satisfy Client requirements). - from test system documents to system documents (Tests system verify System requirements). -from system documents to system overall document (System requirements are implemented throught overall requirements).
We have already studied about doors suspects links but its process is very tough, whatever we do, the link become suspect. We also studied how to manage an object attribute but if the requirement have several links and only one become suspect, we don't know which one is suspect. So we have done our own suspects links by creating an attribute on links. It becomes suspect only when some object attributes change (not all) by a dxl trigger. When the link to be suspicious is an outlink, it works perfectly, but for inlinks, we cannot change its attribute if its source module is not edited.
Regards, Estelle
So let me summarize the processes, you want to achieve here: a) Someone editing the high level document (e.g. Client Requirements), changes some special attributes. All In-Links (e.g. from System requirements) become suspect. Out-links stay the same. b) Someone editing a lower level document (e.g. System Requirements), sees that links inside the document are suspect. He validates the links and wants to clear the suspicion. For the above processes, you do not need to modify inlinks at all. What process, do you need to modify to inlinks? Maybe this one? c) Someone editing the high level documents, wants to decide whether or not the in-links should become suspect? Regards, Mathias |
Re: DXL code at opening a module Mathias Mamsch - Mon Dec 19 09:34:16 EST 2016 So let me summarize the processes, you want to achieve here: a) Someone editing the high level document (e.g. Client Requirements), changes some special attributes. All In-Links (e.g. from System requirements) become suspect. Out-links stay the same. b) Someone editing a lower level document (e.g. System Requirements), sees that links inside the document are suspect. He validates the links and wants to clear the suspicion. For the above processes, you do not need to modify inlinks at all. What process, do you need to modify to inlinks? Maybe this one? c) Someone editing the high level documents, wants to decide whether or not the in-links should become suspect? Regards, Mathias Forgot to explain a,b): - For achieving something like this, you would make a special Date attribute (e.g. "Last Relevant Change", that your trigger fills whenever a relevant attribute is modified. - You would need a custom layout DXL that compares the creation date of the link or (if present) the last review date of the link with the "Last Relevant Change" date (or create date) of the object. If the object was created after the link has been made, you obviously have a problem :-), but if the Review Or Link creation is not later than the last relevant change on the target object, then the link is suspect. To clear the suspicion from the source module, you simply set the review date on the link. |
Re: DXL code at opening a module In fact a), b) and c) :-) I didn't think about special Date attribute. So for a) and b) I'll try this way then.
the c) solution is for me one step later, when users will have the choice between - "modified with impacts" => links will be suspects, - and "modified without impacts" => links will not be suspects.
Thanks a lot for your replies. Estelle
|
Re: DXL code at opening a module Estebell - Mon Dec 19 08:35:08 EST 2016 Thank's a lot for all your advice. Well I'll try to give you some information about our process.
We have some client documents (level 1), system documents (level 2) and product documents (level 3). Level 2 document can sometimes have one document "Overall". We also have tests documents at each level. Our links are created : - from (level-1) to (level) documents. (System requirements satisfy Client requirements). - from test system documents to system documents (Tests system verify System requirements). -from system documents to system overall document (System requirements are implemented throught overall requirements).
We have already studied about doors suspects links but its process is very tough, whatever we do, the link become suspect. We also studied how to manage an object attribute but if the requirement have several links and only one become suspect, we don't know which one is suspect. So we have done our own suspects links by creating an attribute on links. It becomes suspect only when some object attributes change (not all) by a dxl trigger. When the link to be suspicious is an outlink, it works perfectly, but for inlinks, we cannot change its attribute if its source module is not edited.
Regards, Estelle
> We have already studied about doors suspects links but its process is very tough, whatever we do, the link become suspect.
One comment on that: You can influence this behavior: only changes in attributes whose definition is set to "Affect change date == true" will result in suspect links. So, you might want to change the definition of your "special attributes" (perhaps set them to Affect change bar == true and Affect change date == false), and then you can use the basic functionality of link suspicions. |
Re: DXL code at opening a module Mike.Scharnow - Mon Dec 19 17:13:16 EST 2016 > We have already studied about doors suspects links but its process is very tough, whatever we do, the link become suspect.
One comment on that: You can influence this behavior: only changes in attributes whose definition is set to "Affect change date == true" will result in suspect links. So, you might want to change the definition of your "special attributes" (perhaps set them to Affect change bar == true and Affect change date == false), and then you can use the basic functionality of link suspicions. Hi Mike, If I change the definition of my attributes, the basic functionnality is more efficient for my process. There is still one thing to improve in that case : how do I do when I correct some typos or anything that may not change the way of the requirement ? In this case, the links become suspects but would not. I have an attribute validation. Perhaps it is possible by triggers to change suspect links to unsuspect when the validation attribute is "without impacts" ?
Estelle |
Re: DXL code at opening a module Estebell - Wed Dec 21 03:23:18 EST 2016 Hi Mike, If I change the definition of my attributes, the basic functionnality is more efficient for my process. There is still one thing to improve in that case : how do I do when I correct some typos or anything that may not change the way of the requirement ? In this case, the links become suspects but would not. I have an attribute validation. Perhaps it is possible by triggers to change suspect links to unsuspect when the validation attribute is "without impacts" ?
Estelle Well, yes, it is possible to change a link to unsuspect, but generally, I would recommend against doing so. In previous projects I learned that it is usually not possible to distinguish important from not-so-important changes in an automated way, I would not be able to write a program to distinguish a typo correction from a change that is meaningful, so I would advise to either treat every change as a possible suspicion or add a requirement status attribute (changed, reviewed, rework, ...) that is to be filled manually.
After all, the links show "suspicions", not "probable impacts", so, the whole idea of suspicions is to review every change in the "other" side of the link and to decide whether the change is relevant or not. Note that in case of typos, reviews / suspicion clearance can be done easily and fast.
Anyway, having said this, if you look at the details of a link where a suspicion has been cleared and at the link module, you see that "clearing a suspicion" creates / modifies link attributes "Suspicion Cleared Forwards" and "Suspicion Cleared Backwards" of type Date. So, all suspect links are links where a) the remote object has been changed later than the local object and b) no "Suspicion Cleared" attribute exists or if it exists, it is older than the latest change of the remote object. You can play around with these attributes and mimick the built-in behavior to build your own "clear suspicion" function. Of course, nobody will give you a warranty that your own function does the same as the builtin one.
|